Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.

Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:

Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.

Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:

• Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт:
  /usr/lib/applmgmt/support/scripts/autogrow.sh
• Помимо расширения раздела из SSH, это можно сделать через интерфейс Virtual Appliance Management Interface (VAMI) REST API, который можно вызвать удаленно методом POST /appliance/system/storage/resize.

Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.

Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:

Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:

Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:

Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:

Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:

Connect-CisServer -Server 192.168.1.150 -User administrator@vghetto.local -Password VMware1!

$diskResize = Get-CisService -Name 'com.vmware.appliance.system.storage'

$diskResize.resize()

В итоге, результат будет виден в выводе команды df: раздел, как и виртуальный диск VMDK, увеличился до 5 ГБ:

Компания StarWind, производящая лучший продукт Virtual SAN, предназначенный для создания отказоустойчивых iSCSI-хранилищ под виртуализацию, выпустила интересный документ, который будет полезен всем администраторам платформы Hyper-V - "VHD Set in MS Windows Server 2016".

Как некоторые из вас знают, в Windows Server 2016 появился новый тип виртуального диска VHD set, который предназначен для организации общего доступа к диску со стороны нескольких виртуальных машин (для баз данных SQL Server, файловых серверов и прочего):

На самом деле, это не новый диск, а улучшенный диск типа Shared VHDX, который получил новые возможности, но сохранил ту же самую логику и архитектуру. Вот что нового появилось в VHD set:

• Возможность бэкапа и репликации VHD set на уровне хоста
• Изменения размера диска VHD Set на лету, без остановки виртуальной машины
• Возможность горячей миграции
• Создание снапшотов такого диска

Этот диск состоит из двух основных файлов:

• vhds - конфигурационный файл, который содержит метаданные
• avhdx ("automatic .vhdx") - данные виртуального диска, он может быть fixed или dynamic

Об остальном, включая настройку VHD set, читайте в документе StarWind.

Как мы недавно писали, в новой версии платформы виртуализации VMware vSphere 6.5 появившийся очень давно механизм VMware Storage IO Control (SIOC) теперь работает посредством политик хранилищ (Storage Policies) на базе интерфейса vSphere APIs for IO Filtering (VAIO). О том, как раньше работал SIOC на практическом примере мы уже писали вот тут. А тут мы упоминали о Storage Policy Based Management (SPBM).

Давайте теперь посмотрим, как все это взаимодействует вместе. Во-первых, надо сказать, что Storage IO Control начинает работать, когда на хосте ощущается недостаток ресурсов хранилища (пропускной способности) и виртуальные машины начинают конкурировать между собой. По умолчанию этот механизм выключен, поэтому машины разбираются между собой на общих основаниях.

Давайте включим SIOC для отдельного хранилища. Для этого в vSphere Client нажмем на него правой кнопкой и выберем "Configure SIOC":

Тут мы видим, что есть некоторый Congestion Threshold - это зачение в процентах загруженности хранилища (по пропускной способности) или по Latency (задается вручную), при превышении которого будет включен механизм борьбы за ресурсы SIOC. Также важна галка "Exclude I/O statistics from SDRS" - это Network-Aware DRS, то есть теперь механизм балансировки нагрузки по хранилищам SDRS по умолчанию не перемещает машины на загруженные в плане сети хосты (это можно отключить при желании).

Далее посмотрим на политики хранилищ. Для этого пойдем в раздел VM Storage Policy и далее в Storage Policy Components, где посмотрим параметры дефолтной политики "Normal":

Вот тут-то мы и видим параметры VMware SIOC, которые можно регулировать для данной политики, которая впоследствии будет применена к виртуальной машине или ее отдельным виртуальным дискам. Все то же самое - резервация и лимиты по IOPS, а также shares - то есть доли, которые будут иметь от общего объема shares объекты данной политики.

При создании новой политики хранения можно задать предопределенный набор Reservation, Limit и Shares в качестве компонента Datastore IO Control:

Также в политики хранения можно в качестве правил (rules) задавать определенные сервисы предоставляемые хостом (это понятие Line of Service) - например, шифрование дисков, кэширование, репликация и прочее. Все это доступно для редактирования при задании правил в рамках новой политики хранения (VM Storage Policy):

Ну а для назначения политики надо использовать пункт VM Policies в контекстном меню виртуальной машины, далее выбрать пункт Edit VM Storage Policies:

И далее назначаем стандартную или кастомную политику хранения для всех объектов виртуальной машины (Apply to all) или для отдельных виртуальных дисков (по умолчанию стоит политика, назначенная для всего датастора):

Таким образом, теперь SIOC и SPBM интегрированы в рамках единого рабочего процесса и удобны в использовании при управлении классами обслуживания в плане хранилищ для виртуальных машин и отдельных дисков VMDK.

Продолжаем вас знакомить с особенностями продукта для организации программных хранилищ под виртуализацию номер 1 - StarWind Virtual SAN. На этот раз приглашаем вас на бесплатный вебинар "Benefit from future storage technologies now with StarWind and Kazan", который пройдет 1 ноября в 22-00 по московскому времени.

Технологии NVMe и 3DXpoint flash являются будущим технологий хранения с самой высокой пропускной способностью. Эти технологии будут легко справляться с самыми I/O-интенсивными нагрузками приложений, такими как обработка транзакций OLTP, анализ данных в режиме реального времени, а также, в более широком масштабе - обработкой больших объемов данных.

В современных All-Flash-датацентрах существующие протоколы хранения серьезно устарели и создают узкие места. Эта проблема решается с помощью недавно разработанных передовых протоколов, таких как NVMe-over-fabrics (NVMf), iSER или SMB Direct. Они используют RDMA для улучшения производительности по сравнению с существующими протоколами, такими как NFS и iSCSI.

Регистрируйтесь на вебинар StarWind и Kazan Networks, чтобы узнать, как можно реализовать хранилище NVMe уже сегодня с NVMf-таргетами от Kazan Networks и инициаторами NVMf от компании StarWind.

Как-то один из наших читателей спросил, как можно узнать, какие из хостов VMware ESXi в кластере используют данное виртуальное хранилище (датастор)? Ведь использовать они его могут не только для хранения виртуальных машин, исполняемых на нем, но и для хартбитов - то есть сигналов доступности VMware HA, передаваемых через лок-файлы на этих датасторах.

Для этой цели можно использовать утилиту vSphere On-disk Metadata Analyzer (VOMA), которая умеет проверять консистентность метаданных тома VMFS, а также покажет вам информацию о том, какие хосты ESXi его используют.

Для начала нужно узнать имя датастора в формате определения устройства. Посмотрим список имен устройств через esxcli:

esxcli storage vmfs extent list

Мы увидим вот такую картину:

В колонке Device name мы видим имя устройства - eui.5adcee56739fb3ea:1. Теперь с помощью VOMA проведем проверку этого девайса и выведем метаданные этого тома VMFS:

voma -m vmfs -f check -d /vmfs/devices/disks/eui.5adcee56739fb3ea:1

Если том не в порядке, то будет выведено вот такое сообщение:

Error: Missing LVM Magic. Disk doesn’t have a valid LVM Device Error: Failed to Initialize LVM Metadata

Ну а если все окей, то вот что мы получим:

Тут мы видим, что устройство (том VMFS/датастор) используется одним хостом с соответствующим MAC-адресом. Дальше уже дело техники найти этот хост ESXi.

Если вы хотите вывести результаты работы данной команды VOMA в файл, то можно использовать ключ -s:

voma -m vmfs -f check -d /vmfs/devices/disks/eui.5adcee56739fb3ea:1 -s /tmp/output.txt

Продолжаем серию заметок об анонсах прошедшего VMworld Europe 2016, где компания VMware рассказала о ближайших обновлениях своей продуктовой линейки. Напомним основные из них:

• Анонсирована новая версия платформы виртуализации VMware vSphere 6.5
• Анонсы VMworld Europe 2016: VMware представила Virtual SAN 6.5
• Анонсирован VMware Site Recovery Manager 6.5 - что нового?
• VMware и Amazon Web Services анонсировали совместное публичное облако

Как многие из вас знают, у VMware есть технология Virtual Volumes (VVols), которая позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

По сути, Virtual Volumes - это новый способ организации хранилищ в виде удобном для массива, когда используется не традиционная файловая система VMFS, а массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).

Между тем, многие администраторы крупных инфраструктур не спешили использовать VVols, так как эта технология, несмотря на ее поддержку некоторыми дисковыми массивами, не позволяла реализовать некоторые возможности, например, репликацию на уровне дискового массива.

Ну и, соответственно, анонсированные возможности новой версии VVols 2.0:

1. Поддержка репликации на уровне дискового массива.

Ранее для томов VMFS в целях обеспечения отказо- и катастрофоустойчивости, а также достижения нулевого RPO, менеджеры датацентров применяли технологию репликации на уровне СХД (Array-based replication, ABR). Для виртуальных машин на базе VVols 2.0 эта технология становится лучше - теперь можно реплицировать не весь том VMFS целиком, а отдельную виртуальную машину (и даже отдельные виртуальные диски). Также несколько ВМ можно реплицировать в рамках одной Replication Group.

Эта группа виртуальных машин может быть объединена, например, по признаку принадлежности единому сервису, а не по признаку "машины лежат на одном томе", как это было с хранилищами VMFS.

Вот как это работает:

• Технология репликации конкретного вендора коммуницирует с vSphere посредством механизма VASA (vSphere APIs for Storage Awareness).
• Администраторы виртуальной инфраструктуры создают политики хранилищ ВМ, содержащие желаемые требования к репликации, которые должны обеспечиваться системой хранения.
• Когда машина развертывается, администратор:
  • Выбирает политику хранилищ, для которой доступна репликация
  • Выбирает совместимый датастор
  • Задает Replication Group, в которую нужно поместить ВМ
  • Завершает процедуру развертывания.

Replication Group, которую задает пользователь, позволяет добавить несколько ВМ в единую группу доступности. Эти группы обслуживаются со стороны компонента VASA Provider (он содержит в себе структуру томов VVols и реализован на уровне дискового массива или отдельной ВМ).

Интересно, что одна Replication Group поддерживает несколько целевых хранилищ. Одну и ту же группу можно реплицировать, например, сразу в две географически разнесенных локации:

2. Автоматизация аварийного восстановления (Disaster Recovery).

VMware vSphere 6.5 предоставляет расширенный API и команды PowerCLI, которые позволяют обеспечить окрестрацию процесса аварийного восстановления. Вот какие рабочие процессы (Replication Workflows) поддерживаются этими средствами:

• Replication Discovery – это средства, с помощью которых технология VVol disaster recovery обнаруживает текущие связи между двумя доменами.
• Sync Replication Group - синхронизация между основной площадкой и резервными сайтами.
• Test Failover – способ убедиться, что восстановленные сервисы на резервной площадке будут нормально работать после восстановления. После теста администратор может переместить тестируемые сервисы в продакшен.
• Disaster Recovery and Planned Migration – для запланированной миграции сервисов с одной площадки на другую процесс синхронизации может быть инициирован с резервной площадки.
• Setting up protection after a DR event – после восстановления сервисов на резервной площадке, администратор может запустить репликацию в обратном направлении, обеспечив защиту площадки, теперь ставшей основной.

3. Концепция Line of Service.

Спецификация интерфейса VASA 3.0 вводит понятие линии сервиса (Line of Service). Это группа связанных сущностей, таких как inspection, compression, encryption, replication, caching или persistence, выполняющих определенную задачу. Например, для сущности Replication можно создать и сконфигурировать линию сервиса и назначить ее некоторым политикам хранилищ (storage policies), которые уже будут назначаться виртуальным машинам. Это упростит настройку новых сервисов для больших инфраструктур.

4. Поддержка Virtual Volumes для Oracle RAC.

В дополнение к репликации на уровне дисковых массивов, технология VVols 2.0 будет полностью поддерживаться для кластеров Oracle RAC (как сейчас это поддерживается для томов VMFS). Это позволит защитить еще больше бизнес-критичных приложений.

Как и большинство других продуктов, анонсированных на VMworld Europe 2016, доступность технологии Virtual Volumes ожидается до конца этого года. А вот ее поддержка на уровне систем хранения - уже дело 2017 и более поздних лет.

На проходящей сейчас конференции VMworld Europe 2016 в Барселоне компания VMware анонсировала даже больше продуктов, чем на VMworld 2016 в Лас-Вегасе (там было больше про технологии). Напомним анонсы уже этого, европейского VMworld:

• Анонсирована новая версия платформы виртуализации VMware vSphere 6.5
• VMware и Amazon Web Services анонсировали совместное публичное облако

Ну а сейчас мы расскажем про обновление средства для создания отказоустойчивых кластеров хранения VMware Virtual SAN 6.5. Напомним, что о прошлой версии Virtual SAN 6.2 мы писали здесь, а про VSAN 6.0 можно почитать вот тут.

Давайте посмотрим, что нового в VMware VSAN 6.5:

1. Обновленные Virtual SAN API и vSphere PowerCLI.

Теперь интерфейсы доступа из командной строки и внешних систем были существенно обновлены и доработаны. Стало возможным автоматизировать конфигурацию и управление настройками кластера, дисковых групп, доменов отказа (fault domains) и растянутых кластеров. Также можно управлять различными активностями, такими как режим обслуживания и выключение кластера. Более подробно можно все это увидеть вот в этом видео:

Также через PowerCLI можно отслеживать состояние кластера Virtual SAN.

2. Поддержка двухузловой конфигурации через кросс-кабели.

Ранее кластер Virtual SAN можно было собрать только из трех или более узлов, что препятствовало внедрению технологии в небольших компаниях и филиалах. Теперь же можно создать двухузловую конфигурацию, где хосты соединены между собой кросс-кабелями (без коммутаторов) и там развертывать и виртуальную инфраструктуру, и хранилища виртуальных машин.

Также важно отметить, что теперь лицензирование Virtual SAN for ROBO поддерживает All-Flash конфигурации. Лицензия называется Virtual SAN for ROBO Advanced и позволяет использовать компрессию, дедупликацию и защиту от ошибок (erasure coding).

3. Увеличенная гибкость Virtual SAN 6.5.

Теперь таргеты Virtual SAN можно использовать для физических серверов, что дает решению намного больше гибкости в плане хранения данных предприятия. Функциональность iSCSI targets для Virtual SAN управляется таким же образом, как и виртуальные объекты через механизм Storage Policy Based Management (SPBM).

Также поддерживаются дедупликация, компрессия, мирроринг и erasure coding. Для аутентификации используется CHAP и Mutual CHAP.

4. Поддержка контейнеров.

Средствами механизма vSphere Integrated Containers Engine технология Virtual SAN 6.5 поддерживает контейнеры Docker и другие. Специальный драйвер Docker Volume Driver для vSphere позволяет управлять данными контейнеров, которые размещены на хранилищах VMFS, NFS и Virtual SAN.

Кроме того, в рамках данной новой функции предоставляется API для развертывания контейнеров на хранилищах Virtual SAN, а также средства перемещения виртуальных машин с контейнерами между хостами без перемещения их данных.

5. Поддержка нового аппаратного обеспечения.

Вместе с VMware vSphere 6.5 средства Virtual SAN 6.5 поддерживают новое аппаратное обеспечение, такое как диски 512e очень большой емкости, а также протоколы доступа к SSD-накопителям по шине PCIe - NVMe. Это на идеальных тестах дает до 150 тысяч IOPS на один хост. Также теперь полноценно поддерживается большой спектр хранилищ All-Flash.

Обновленная версия решения VMware Virtual SAN 6.5 будет доступна для загрузки до конца 2016 года.

Компания StarWind, основной производитель решения Virtual SAN для создания отказоустойчивых кластеров под виртуализацию, 20 октября проведет бесплатный вебинар "StarWind VSAN with VMware Virtual Volumes: Manage your operational model easily".

Вебинар пройдет 20 октября в 21-00 по московскому времени.

На вебинаре сотрудники компании расскажут о том, как решения StarWind работают с технологией VMware Virtual Volumes (VVOLs). Также будет живое демо работы продукта Virtual SAN.

Регистрируйтесь и приходите!

Какое-то время назад мы анонсировали вебинар "Accelerate your performance by deploying iSER to your StarWind infrastructure", который проводила компания StarWind - ведущий поставщик программных решений для создания отказоустойчивых хранилищ под виртуализацию.

В этом вебинаре было рассказано поддержке iSER (iSCSI Extensions for RDMA) - расширении модели транспорта iSCSI с RDMA. iSER работает в разы быстрее, чем iSCSI и весьма прост в управлении. В рамках набора протоколов RDMA, эта технология обеспечивает более высокую пропускную способность при передаче для блочных хранилищ.

На днях стала доступной видеозапись этого вебинара:

Посмотрите - всего 15 минут интересной информации об iSER. Не каждый день такое рассказывают.

В блоге CTO компании StarWind Антона Коломейцева есть интересный тест файловой системы ReFS, которая появилась в серверной ОС Windows Server 2016. В статье "ReFS: Performance" Антон детально рассматривает различные аспекты производительности ReFS, а также подробно описывает конфигурацию среды тестирования и сам процесс его проведения.

Интересен вывод о том, что ReFS с включенной фичей FileIntegrity работает как файловая система Log-Structured File System (LSFS), что очень хорошо для виртуальных машин, так как мелкие команды ввода-вывода объединяются в большие пачки, что позволяет избежать эффекта I/O-блендера.

В общем, интересная статья - почитайте.

Компания StarWind, известная своим лучшим в отрасли продуктом Virtual SAN для создания отказоустойчивых программных хранилищ под виртуализацию, проводит бесплатный вебинар "Accelerate your performance by deploying iSER to your StarWind infrastructure".

StarWind традиционно поддерживает все новейшие технологии и протоколы работы с хранилищами, а в этом вебинаре будет рассказано о поддержке iSER (iSCSI Extensions for RDMA) - расширении модели транспорта iSCSI с RDMA.

Вебинар пройдет 15 сентября в 22-00 по московскому времени.

iSER работает в разы быстрее, чем iSCSI и весьма прост в управлении. В рамках набора протоколов RDMA, эта технология обеспечивает более высокую пропускную способность при передаче для блочных хранилищ. Он имеет самую низкую задержку и низкую загрузку процессора. Кроме того, эта технология на сегодняшний день стабильна и сохраняет все основные преимущества протокола iSCSI, такие как безопасность и высокая доступность.

Регистрируйтесь на вебинар, чтобы узнать о работе iSER в решении StarWind Virtual SAN.

Вы уверены, что знаете, что происходит на ваших датасторах? Где хранятся ваши ISO-образы? Сколько у вас «осиротевших» (orphaned) виртуальных дисков? Каков их размер, и как давно они там? И что ещё занимает совсем недешёвое пространство на вашей СХД? Функция Search-Datastore из моего PowerCLI модуля Vi-Module ответит вам на все эти и многие другие вопросы.

На сайте проекта VMware Labs появилась очередная утилита HCIbench, которая может оказаться полезной тем, кому требуется провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Решение HCIbench позволяет посредством скрипта настроить развертывание новых виртуальных машин, скоординировать в них запуск рабочих нагрузок, агрегировать и вывести результаты тестирования, а также собрать необходимые данные для целей траблшутинга. Ну и тут надо добавить, что HCIbench разработан не только для инфраструктуры VIrtual SAN, но и для любой другой гиперконвергентной инфраструктуры хранилищ, например StarWind.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду Vdbench, какие действия необходимо выполнить в кластере хранилищ.

Вводим число виртуальных машин и дисков, а также их размер:

Задаем тестовую конфигурацию:

Задаем параметры тестирования виртуальных дисков:

Решение состоит из двух компонентов:

• Виртуальный модуль Controller VM, на котором установлены:
  • Ruby vSphere Console (RVC)
  • Утилита Virtual SAN Observer
  • Automation bundle
  • Файлы конфигурации
• Тестовая виртуальная машина Linux, используемая как шаблон.

Ну и вот какие задачи может выполнять HCIbench:

• Соединение с тестируемым окружением Virtual SAN. Утилита может быть в отдельной инфраструктуре vSphere, но нужно иметь доступ к целевому кластеру хранилищ.
• Развертывание тестовых виртуальных машин с ОС Linux, основываясь на введенных параметрах пользователя (число машин и число виртуальных дисков на одну машину, а также их размер).
• Опциональный запуск команды dd на каждом из виртуальных дисков, чтобы инициализировать хранилища и создать диски полного размера (thick).
• Передача параметров VDbench на каждую из тестовых ВМ. В файле конфигурации описана целевая нагрузка и спецификация ее выполнения.
• Запуск утилиты Virtual SAN Observer перед началом тестирования и генерация статистик по завершению тестов.
• Удаление тестового окружения инфраструктуры виртуальных машин.
• Сбор и агрегация данных VDbench.

В итоге мы получаем вот такие графики производительности в Virtual SAN Observer:

Утилита HCIbench поставляется в виде готового виртуального модуля и имеет веб-интерфейс конфигурации. Скачать HCIbench можно по этой ссылке. Инструкция по развертыванию и использованию доступна тут.

Компания StarWind, выпускающая лучший в отрасли продукт для создания отказоустойчивых хранилищ iSCSI для виртуальных машин, опубликовала интересный документ "StarWind Asynchronous Replication. Configuration Scenarios" об асинхронной репликации для географически разделенных площадок:

Как правило асинхронная репликация происходит на резервную инфраструктуру в рамках Disaster Recovery стратегии предприятия. Зачастую, соединение с этой инфраструктурой организовано по низкоскоростному каналу, поэтому асинхронная репликация в этом случае - единственный способ откидывать копию данных в целях катастрофоустойчивости.

В документе вы найдете описание этой технологии, а также основные настройки, которые существенно влияют на процесс. Например, репликацию данных можно запускать по планировщику, чтобы не загружать основной канал в рабочие часы:

Остальное - в документе.

Автор: Роман Гельман

Когда вы стираете ВМ через портал Microsoft Azure, у вас нет опции также удалить относящиеся к ВМ объекты, такие как виртуальные сетевые интерфейсы и виртуальные диски.

Что такое потерянные (orphaned) виртуальные диски - это *.vhd файлы, которые находятся на Storage Accounts, потребляя дорогое пространство на СХД, но не относятся ни к одной ВМ.

Как всегда, на помощь нам придёт PowerShell. Представляю вам очередную функцию Get-AzOrphanedVhd моего Azure PowerShell модуля, которая найдёт все потерянные виртуальные диски во всех Resource Groups и на всех Storage Accounts. Эта простенькая функция вообще не имеет параметров!

Всё, что нужно для её использования - это залогиниться в ваш Azure аккаунт при помощи Login-AzureRmAccount, выбрать интересующую вас подписку (Subscription) при помощи Select-AzureRmSubscription и просто запустить Get-AzOrphanedVhd.

Все свойства, возвращаемые функцией интуитивно понятны. Хочу заострить ваше внимание только на этих двух:

• LastWriteDays - количество дней с момента последнего изменения диска.
• Modified - дата изменения диска в вашем локальном времени.

Двум переменным среды $WarningPreference и $ErrorActionPreference присваивается значение SilentlyContinue, чтобы избежать подобного рода предупреждений и ошибок.

Учтите, что даже если диск не относится ни к одной ВМ, это абсолютно не значит, что он не содержит важную информацию! Подумайте дважды прежде, чем удалять какой-либо диск.

Если вы всё-таки решили стереть один или несколько дисков, вы можете это сделать через портал (GUI) или при помощи командлета Remove-AzureStorageBlob.

Обязательно просмотрите справку по Remove-AzureStorageBlob, он поддерживает очень много параметров.

PS C:\> Get-Help Remove-AzureStorageBlob –Full

Также посмотрите примеры использования Get-AzOrphanedVhd.

PS C:\> Get-Help Get-AzOrphanedVhd –Examples

Для желающих почитать статью в оригинале, прилагаю ссылку на блог автора.

Компания StarWind Software, производитель лучшего продукта Virtual SAN для создания программных отказоустойчивых iSCSI-хранилищ, приглашает на вебинар посвященный конфигурации виртуальных хранилищ в соответствии с требованиями клиента - "Configure your virtual storage according to your requirements".

На мероприятии вы узнаете много интересного о конфигурации виртуальных хранилищ, параметрах RAID, концепции software-defined storage, организации хранилищ для нескольких гипервизоров и многом другом.

Вебинар пройдет 11 августа в 22-00 по московскому времени. Регистрируйтесь!

Компания StarWind, известная своим лучшим продуктом Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию, проводит бесплатный вебинар "Manage StarWind Virtual SAN from anywhere". На мероприятии будет рассказано о новой веб-консоли продукта, которая позволит управлять решением из любой точки через браузер (StarWind Web Console).

Теперь для управления решением Virtual SAN можно будет использовать не только Windows-машину, но и любой браузер, в том числе мобильных устройств на платформах Android и iOS. Кроме того, администраторы VMware смогут использовать специальный StarWind vCenter plugin для веб-клиента vSphere Web Client.

Вебинар пройдет 28 июля в 22-00 по московскому времени. Зарегистрируйтесь!

Многие администраторы VMware vSphere часто используют снапшоты для отката виртуальных машин в базовую точку после внесения в них экспериментальных изменений. Но вы же знаете, что снапшоты - это плохо, поэтому в некоторых ситуациях можно заменить этот процесс на более эффективный, так как снапшот можно забыть удалить, их удаление грузит дисковую подсистему и т.п.

Итак, иногда независимые (independent) диски могут оказаться вам полезными. Если вы зайдете в настройку дисков виртуальной машины, то увидите там такие опции:

Независимость таких дисков заключается в том, что они работают независимо от снапшотов, то есть при снятии снапшота и откате к ним, независимые диски остаются в том же состоянии. И тут есть 2 подвида таких дисков:

• Persistent (постоянный) - этот диск является обычным диском для записи данных, но его не касаются снапшоты.
• Nonpersistent (непостоянный) - этот диск является Redo-диском, то есть если вы выключаете виртуальную машину или откатываете ее к снапшоту - изменения, сделанные в этом диске, сбрасываются.

Как раз Nonpersistent-диски - это то, что можно иногда использовать вместо снапшотов. Сделали базовую машину, поэкспериментировали в ней, выключили - и она откатилась к базовому состоянию.

А вот еще кейс, который может научить вас использованию дисков сразу всех трех типов (обычных, независимых-постоянных и независимых-непостоянных). Например, вы сделали веб-сайт, который меняться не будет еще очень долго. Делаете виртуальную машину с тремя дисками:

• Обычный - для файлов веб-сервера
• Nonpersistent - для контента веб-сайта
• Persistent - для логов веб-сайта

Теперь, если этот сайт кто-то поменяет или заразит, какой-то фигней, можно будет просто перезагрузить виртуальную машину - и это откатит ее в начальное состояние контента (непостоянный диск), но сохранит логи для анализа действий злоумышленника (постоянный диск).

В общем, независимые диски как-то не очень используются, но ведь иногда они вполне подойдут для решения некоторых админских задач.

На днях мы писали о том, что компания VMware выпустила релизную версию своей минимальной операционной системы Photon OS 1.0, которая предназначена для исполнения виртуальных контейнеров Docker. Многие сразу задумались о том, как дело обстоит с работой контейнеров с хранилищами своих данных.

Как раз в этой связи компания VMware выпустила технологическое превью драйвера vSphere Docker Volume Driver, позволяющего напрямую работать с виртуальными хранилищами прямо из контейнеров Docker (версии 1.9 или выше).

Архитектура решения выглядит так:

Как видно из картинки, нам потребуется установить Volume Driver на серверы VMware ESXi, а также плагины vSphere Docker Volume Plugin на виртуальные машины Docker Host, где будут исполняться наши контейнеры. Также мы видим, что в качестве хранилищ поддерживаются практически все, что поддерживает платформа vSphere: тома VMFS (локальные и общие), NFS-хранилища, а также тома Virtual SAN (и соответственно их политики по обеспечению избыточности данных в целях отказоустойчивости).

Рассмотрим развертывание решения vSphere Docker Volume Driver по шагам.

1. На серверы VMware ESXi 6.0 или выше устанавливается компонент vSphere Data Volume Driver в виде обычного VIB-пакета.

Делается это примерно так:

[root@esxi-hp-08:~] esxcli software vib install \

  -d "/vmfs/volumes/569c904a-8880cc78-a5c7-a0369f56ddc0/\

  vmdkops/vmware-esx-vmdkops-0.1.0.tp.zip" --no-sig-check -f

  Installation Result

Message: Operation finished successfully.

Reboot Required: false

VIBs Installed: VMWare_bootbank_esx-vmdkops-service_1.0.0-0.0.1

VIBs Removed:

VIBs Skipped:

[root@esxi-hp-08:~]

Предварительно нужно загрузить драйвер по этой ссылке.

2. Проверяем статус установленных пакетов.

[root@esxi-hp-08:~] /etc/init.d/vmdk-opsd status

  vmdkops-opsd is running pid=12343527

[root@esxi-hp-08:~]

3. Развертываем Photos OS, которая будет служить нам как Docker Host.

Скачать Photon OS можно по этой ссылке.

4. Устанавливаем VMDK Plugin (Docker Volume Plugin) на хост ESXi.

Проверяем версию Docker:

root@photon-machine [ ~ ]# docker version

  Client:

Version:      1.11.0

API version:  1.23

Go version:   go1.5.4

Git commit:   4dc5990

Built:        Wed Apr 13 19:36:04 2016

OS/Arch:      linux/amd64

Server:

  Version:      1.11.0

  API version:  1.23

  Go version:   go1.5.4

  Git commit:   4dc5990

  Built:        Wed Apr 13 19:36:04 2016

  OS/Arch:      linux/amd64

  root@photon-machine [ ~ ]# 

  Install the RPM (I’ve used “-U” out of habit, but “-i” can also be used):

Устанавливаем RPM-пакет с плагином в гостевую ОС:

root@photon-machine [ ~ ]# ls

  docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm

  root@photon-machine [ ~ ]# rpm -Uvh docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm

  Preparing...                          ################################# [100%]

  Updating / installing...

  1:docker-volume-vsphere-0:0.1.0.tp-################################# [100%]

  File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'

  Created symlink from /etc/systemd/system/multi-user.target.wants/\

docker-volume-vsphere.service to /usr/lib/systemd/system/docker-volume-vsphere.service.

5. Проверяем статус плагина:

root@photon-machine [ ~ ]# systemctl status docker-volume-vsphere

  * docker-volume-vsphere.service - "Docker Volume Driver for vSphere"

Loaded: loaded (/usr/lib/systemd/system/docker-volume-vsphere.service;\

enabled; vendor preset: enabled)

Active: active (running) since Mon 2016-05-30 09:04:21 UTC; 28s ago

Main PID: 256 (docker-volume-v)

CGroup: /system.slice/docker-volume-vsphere.service

`-256 /usr/local/bin/docker-volume-vsphere

May 30 09:04:21 photon-machine systemd[1]: Started "Docker Volume Driver\

  for....

  Hint: Some lines were ellipsized, use -l to show in full.

  root@photon-machine [ ~ ]#

6. Создаем том для использования его контейнером.

root@photon-machine [ ~ ]# docker volume create --driver=vmdk \

  --name=MyVolume -o size=20gb

MyVolume

7. Проверяем созданный том.

root@photon-machine [ ~ ]# docker volume ls

  DRIVER              VOLUME NAME

vmdk                MyVolume

root@photon-machine [ ~ ]#

8. Смотрим детали.

root@photon-machine [ ~ ]# docker volume inspect MyVolume

  [

  {

  "Name": "MyVolume",

  "Driver": "vmdk",

  "Mountpoint": "/mnt/vmdk/MyVolume",

  "Labels": {}

  }

  ]

root@photon-machine [ ~ ]#

9. Теперь с машины с Photon OS запустим контейнер с образом Ubuntu внутри и направим его хранилище к только что созданному.

root@photon-machine [ ~ ]# docker run -it -v MyVolume:/MyVolume ubuntu bash

  root@bd9410fb4c1d:/# ls

  Myvolume  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  \

  root  run  sbin  srv  sys  tmp  usr  var

  root@fe8c21d003fa:/# df

  Filesystem                                      1K-blocks    Used Available Use% Mounted on

  overlay                                           8122788 6095776   1591356  80% /

  tmpfs                                             4085412       0   4085412   0% /dev

  tmpfs                                             4085412       0   4085412   0% /sys/fs/cgroup

  /dev/disk/by-path/pci-0000:0b:00.0-scsi-0:0:0:0  20642428   44992  19548860   1% /MyVolume

  /dev/root                                         8122788 6095776   1591356  80% /etc/hosts

  shm                                                 65536       0     65536   0% /dev/shm

  root@fe8c21d003fa:/#

  root@bd9410fb4c1d:/# cd Myvolume/

  root@bd9410fb4c1d:/Myvolume# ls

root@bd9410fb4c1d:/Myvolume#

10. Также можно создавать хранилища и на кластерах Virtual SAN.

Тома можно создавать с учетом политики FTT или QoS. Например:

docker volume create --driver=vmdk --name=vol2 -o size=20gb -o vsan-policy-name=FTT=0

11. Сами VMDK-диски с хранилищами Docker можно посмотреть в обычном браузере хранилищ.

Например, для кластера Virtual SAN их можно найти в следующем месте:

Более подробная информация о драйвере размещена тут, тут и тут (там же есть более подробная информация о его развертывании).

Интересный пост о технологии VVols появился на блогах VMware. Дескать, их часто спрашивают - почему средства балансировки нагрузки на хранилища Storage DRS не поддерживаются для томов VVols?

Для ответа на этот вопрос надо рассмотреть, как работает традиционная архитектура хранилищ, которая была до VVols и кластеров Virtual SAN. Обычный дисковый массив или хост можно представить набором носителей двух типов (HDD и Flash), которые дают суммарно некоторую емкость.

Например, у нас 160 ТБ на СХД, которые мы разбиваем на LUN по 8 ТБ, итого получая 20 томов VMFS. Допустим, половина емкости у нас HDD, а половина - SSD. Тогда мы создадим 2 датастор-кластера (datastore cluster), в каждом из которых будет по 10 томов VMFS:

Кластер на SSD-носителях будет хранилищем яруса Gold, а HDD - Silver. Технология Storage DRS предназначена, чтобы балансировать виртуальные машины в рамках яруса между LUN для обеспечения их равномерной загрузки, как по емкости, так и по вводу-выводу. А в случае необходимости машину можно также и перенести между ярусами (Silver->Gold) с помощью технологии Storage vMotion.

Все это вызвано сложной структурой хранилищ, которая "прячет" виртуальную машину от дискового массива, представляя ее в конечном счете как набор дисковых блоков, ничем не отличающихся таковых при подключении физических серверов.

В случае же с VVols дело обстоит совсем иначе: на все хранилище создается один Storage Container, который объединяет собой все 160 ТБ доступной емкости - и Flash, и HDD. И этот контейнер представляет собой единственный объект для хранения виртуальных машин с томами VVols:

То есть все операции по балансировке данных виртуальных машин (на уровне дисковых объектов VVols) передаются на сторону СХД, которая лучше знает, как правильно распределять данные и обеспечивать необходимый уровень обслуживания на базе политик (Storage Policies), привязанных к ярусам. Это, конечно же, требует некоторой работы со стороны производителей систем хранения, зато избавляет от забот саму VMware, которая универсализовала технологию VVols и средства работы с ней.

То есть, VVols не требует наличия Storage DRS - технологии, которая уйдет со временем на уровне отдельных аппаратных хранилищ, но будет полезной для балансировки в среде, где есть несколько СХД или кластеров хранилищ от одного или нескольких вендоров.

Компания StarWind Software, известная своим лучшим продуктом Virtual SAN, предназначенным для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, проводит бесплатный вебинар "Turnkey Storage Appliance Less work for you".

Это мероприятие предназначено для тех, кто хочет узнать о продукте Storage Appliance, представляющем собой законченную программно-аппаратную платформу для создания надежного и быстрого хранилища для виртуальных машин.

Вебинар пройдет 8 июня в 15-00 по московскому времени. Вести вебинар будет Тарас Швед, так что вы спокойно можете задавать вопросы на русском языке.

Регистрируйтесь!

Компания StarWind Software, выпускающая лучший продукт Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию VMware и Microsoft, выпустила интересный документ "StarWind Storage Appliance Overview".

StarWind Storage Appliance - это готовый к развертыванию инфраструктуры хранилищ для гипервизоров VMware ESXi и Microsoft Hyper-V программно-аппаратный комплекс, который можно просто масштабировать по емкости путем приобретения новых узлов, при этом обеспечивается отказоустойчивость всей подсистемы хранения:

Более подробно о таких функциях StarWind Storage Appliance, как файловая система Log-Structured File System (LSFS), серверное кэширование, дедупликация, компрессия данных при передаче, асинхронная репликация и многое другое, вы можете прочитать в документе, а также по этой ссылке.

Зачастую в тестовом окружении вам нужно создать несколько томов VMFS (например, для тестирования технологии Storage DRS и создания кластера хранилищ), но диск на машине только один. В этом случае можно вручную нарезать этот диск на разделы и отформатировать их в тома VMFS 5, которые будут использоваться в качестве виртуальных хранилищ.

Для этих целей можно использовать 2 утилиты, входящие в состав VMware ESXi 6 - PartedUtil и vmkfstools. Помните, что метод, изложенный ниже, не поддерживается для производственных систем. Используйте его только в тестовом окружении!

Итак, заходим на хост ESXi, напрямую или по SSH. Сначала нужно найти имя устройства. Для этого можно воспользоваться командой:

fdisk –l

Либо для подробной информации можно взять следующую:

esxcli storage core path list

В качастве вывода мы получим что-то вроде этого:

sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

UID: sata.vmhba34-sata.0:0-t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

Runtime Name: vmhba34:C0:T0:L0

Device: t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288

Device Display Name: Local ATA Disk (t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288)

Adapter: vmhba34

Channel: 0

Target: 0

LUN: 0

Plugin: NMP

State: active

Transport: sata

Adapter Identifier: sata.vmhba34

Target Identifier: sata.0:0

Adapter Transport Details: Unavailable or path is unclaimed

Target Transport Details: Unavailable or path is unclaimed

Maximum IO Size: 33553920

Можно сделать это и из vSphere Client:

Далее получаем таблицу разделов следующей командой (имя диска берем из поля Device):

partedUtil getptbl "t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288"

Диск этот пуст, и мы получим примерно такой вывод:

msdos

29185 255 63 468862128

Например, вы хотите создать на этом диске 5 разделов (LUN) по 10 ГБ каждый. При размере сектора 512 байт, размер каждого такого диска будет 20971519 секторов. При этом первые 2048 секторов диска надо пропустить, чтобы оставить место под GPT-таблицу и выровнять разделы по лучшим практикам (под 512-байтные секторы).

Получаем следующий план разбиения разделов с номерами начальных и конечных секторов:

P1 2048-20973567

P2 20973568-41945087

P3 41945088-62916607

P4 62916608-83888127

P5 83888128-104859647

Претворяем его в жизнь с помощью partedUtil:

partedUtil setptbl "t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288" gpt "1 2048 20973567 AA31E02A400F11DB9590000C2911D1B8 0" "2 20973568 41945087 AA31E02A400F11DB9590000C2911D1B8 0" "3 41945088 62916607 AA31E02A400F11DB9590000C2911D1B8 0" "4 62916608 83888127 AA31E02A400F11DB9590000C2911D1B8 0" "5 83888128 104859647 AA31E02A400F11DB9590000C2911D1B8 0" 

Что такое "AA31E02A400F11DB9590000C2911D1B8" в данной команде? Это GUID разделов VMFS.

Далее с помощью partedUtil getptbl или другой команды выведем список разделов и получим следующее:

gpt

  29185 255 63 468862128

  1 2048 20973567 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  2 20973568 41945087 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  3 41945088 62916607 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  4 62916608 83888127 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

  5 83888128 104859647 AA31E02A400F11DB9590000C2911D1B8 vmfs 0 

Разделы созданы, осталось отформатировать их под VMFS 5. Для этого воспользуемся утилитой vmkfstools и создадим Datastore 1 на первом разделе диска:

vmkfstools -C vmfs5 -S Datastore1 t10.ATA_____WDC_WD10EALX2D009BA0__________________________WD2DWCATR6576288:1

Аналогичные действия нужно будет проделать и с оставшимися четырьмя датасторами, после чего они станут видны в клиенте vSphere. Более подробно о процедуре изложено в KB 1009829.

В блоге CTO компании StarWind, выпускающей лучшие продукты для создания отказоустойчивых программных хранилищ, появилась интересная запись о встроенной технологии репликации и катастрофоустойчивости Windows Server - Microsoft Storage Replica. В своем посте Антон Коломейцев поясняет, как работает эта штука для синхронного и асинхронного режимов.

Синхронная репликация Microsoft Storage Replica работает так:

1. Приложение записывает данные.
2. Записываются данные журнала (логи) и данные уходят на резервную площадку.
3. На удаленной площадке также записываются логи.
4. С резервной площадки приходит подтверждение записи данных.
5. Для приложения запись данных считается подтвержденной.

Для асинхронной репликации процесс можно представить следующим образом:

1. Приложение записывает данные.
2. Записываются данные журнала (логи).
3. Для приложения запись данных считается подтвержденной.
4. Данные уходят на резервную площадку.
5. На удаленной площадке также записываются логи.
6. С резервной площадки приходит подтверждение записи данных.

Ну и сотрудники StartWind во главе с Антоном решили протестировать Microsoft Storage Replica в рамках четырех различных сценариев. По ссылкам ниже вы можете почитать о результатах этого тестирования:

1. Microsoft Storage Replica: Failover Cluster and File Server Role (Windows Server Technical Preview)
2. Microsoft Storage Replica: Microsoft Failover Cluster and Guest VM Cluster role (Windows Server Technical Preview)
3. Microsoft Storage Replica: Microsoft Failover Cluster and Clustered Hyper-V VM role (Windows Server Technical Preview)
4. Microsoft Storage Replica: Microsoft Failover Cluster and Scale-out File Server role (Windows Server Technical Preview)

В апреле 2016 года компания «ИТ-ГРАД» организовала серию тренингов, посвященных технологиям NetApp для эффективного хранения данных. Компания NetApp не нуждается в отдельном представлении, ведь решения этого производителя пользуются высокой популярностью. Какие темы оказались наиболее обсуждаемыми, расскажем в сегодняшнем материале.

Компания StarWind Software, лидирующий производитель средств для создания отказоустойчивых хранилищ под виртуализацию, 28 апреля проведет вебинар на тему настройки решения для создания виртуальной ленточной библиотеки под хранение резервных копий - "Real Support Case: StarWind Virtual Tape Library Proper Configuration".

На очередном ежечетверговом вебинаре от StarWind вы сможете узнать все о настройке решения StarWind VTL, которое набирает популярность в последние месяцы. Это мероприятие позволит вам узнать о деталях настройки продукта на основе реальных сценариев его использования заказчиками StarWind, а также наглядно увидеть все эти шаги в консоли продукта в рамках онлайн-демо.

Вебинар пройдет 28 апреля в 15-00 по московскому времени. Зарегистрироваться можно по этой ссылке. Мероприятие проводит Богдан Савченко, а значит вы сможете задавать вопросы на русском языке.

Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).

1. Обычный кластер Virtual SAN.

Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:

• NumberOfFailuresToTolerate (FTT)
• NumberOfDiskStripesPerObject (SW)
• FlashReadCacheReservation (FRCR)

то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка Force Provisioning для VM Storage Policy, которая позволяет игнорировать указанные 3 параметра при развертывании новой ВМ в кластере.

Однако надо понимать, что при использовании Force Provisioning происходит не понижение требований кластера к хранилищу виртуальной машины (например, вместо FTT=2 можно было бы проверить FTT=1), а использование следующих параметров:

• NumberOfFailuresToTolerate = 0
• NumberOfDiskStripesPerObject = 1
• FlashReadCacheReservation = 0

То есть нужно просто аллоцировать место под виртуальную машину, совершенно без соблюдения требований к дублированию данных и резервированию кэша.

Но кластер Virtual SAN имеет еще одну специфическую черту - если вы использовали Force Provisioning при недостатке дисковых ресурсов, то когда они освободятся, для хранилища машины будут сделаны реплики дисковых объектов и прочие операции, чтобы она все-таки соответствовала требуемым политикам хранилищ. Администраторам надо иметь эту особенность в виду.

И еще один момент - так как в случае Force Provisioning может храниться только одна копия дисковых объектов, то, например, если при переводе хоста в режим Maintenance Mode случится какой-нибудь сбой с его хранилищем - реально можно потерять эту машину целиком. Делайте бэкап и, по-возможности, не используйте Force Provisioning - старайтесь соблюдать политики хранилищ хотя бы на уровне FTT=1.

2. Растянутый кластер (Stretched Cluster).

В случае растянутого кластера появляется еще один компонент - Witness Appliance, следящий за ситуацией Split Brain, которая может появиться между площадками. Если вырубить этот виртуальный модуль и попытаться включить виртуальную машину или создать новую ВМ, то кластер Virtual SAN (несмотря на то, что он Failed и политика хранилищ не соблюдена) позволит это сделать, правда будет ругаться, что машина не соответствует текущим политикам хранилищ:

В остальном растянутый кластер ведет себя по отношению к Force Provisioning так же, как и обычный.

Не так давно мы писали о том, как поддерживает резервное копирования виртуальных машин на томах Virtual Volumes (VVols) главный продукт в индустрии Veeam Backup and Replication. Технически бэкап ВМ на томах VVols ничем не отличается от стандартного бэкапа в VMware vSphere, так как создание снапшота проходит через единый механизм как для обычных виртуальных хранилищ, так и для Virtual Volumes. Достигается это посредством поддержки продуктом для резервного копирования интерфейса vSphere APIs for Data Protection (VADP).

VADP уже достаточно давно поддерживается решениями для резервного копирования виртуальных машин, поэтому вы можете смело использовать их для бэкапа ВМ на томах VVols, начиная со следующих версий:

Для успешного резервного копирования через VADP надо обязательно иметь доступ к vCenter, делать его резервную копию, а также создать бэкап виртуальной машины, реализующей VASA Provider (VP), если он не физически реализован на массиве, а поставляется как ВМ.

Нужно помнить, что VASA Provider (если это ВМ) содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами. Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP, но необходимо помнить, что это критически важный компонент и неплохо бы делать его резервное копирование.

Важным моментом также является то, что SAN-to-SAN бэкап не работает на томах VVols ни в одном из продуктов для резервного копирования. Причина проста - еще не разработано универсального стабильного API для прямого доступа к томам VVols со стороны медиа-серверов РК.

Важный момент касается снапшотов для томов VVols. Если в традиционных хранилищах не рекомендовалось делать более 2-3 снапшотов (хотя поддерживалось дерево до 32 штук) и хранить их следовало не более 24-72 часов, то для Virtual Volumes все работает несколько иначе:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски. Ну а мораль такова: снапшоты с VVols уже не так плохи, как раньше!

Ну и несколько полезных ресурсов о Virtual Volumes:

• VMware vSphere Virtual Volumes FAQs
• What’s New: vSphere Virtual Volumes
• Benefits of Virtual Volumes
• More VVol Snapshot Goodness
• VVol for Database Backup and Recovery
• Hands on Lab HOL-SDC-1627 – VVol, Virtual SAN & Storage Policy-Based Management

Интересная и полезная штука обнаружилась на одном из блогов, посвященных технологиям виртуализации - утилита VMware ESXi SCSI Sense Codes Decoder. Она позволяет декодировать сообщения, появляющиеся в файле журнала vmkernel.log, когда что-то идет не так при работе хост-сервера ESXi с хранилищами по протоколу блочного доступа SCSI.

Например, вы видите вот такое сообщение:

2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO: 2315: Cmd(0x4124003edb00) 0x12, CmdSN 0x51 to dev “naa.[…]” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

Это, на самом деле, 6 статус-кодов (они выделены жирным выше), которые можно разложить следующим образом, подставив значения в форму ESXi SCSI Sense Codes Decoder:

В качестве результата вы получите расшифровку статус-кодов SCSI, которая поможет вам в решении той или иной проблемы:

Пользоваться утилитой ESXi SCSI Sense Codes Decoder можно только онлайн.

Как вы знаете, у главного производителя средств для создания программных отказоустойчивых хранилищ под виртуализацию, компании StarWind, есть бесплатное издание флагманского продукта StarWind Virtual SAN Free.

В марте на портале ресурсов StarWind Resource Library появилась целая пачка интересных документов, касающихся различных решений и технологий, в том числе и отдельный документ по StarWind Virtual SAN Free.

Этот документ поможет вам понять, чем именно бесплатный StarWind Virtual SAN может вам пригодиться в инфраструктуре небольшого предприятия или филиала.

Напомним, что отличия платной и бесплатной версии решения приведены вот в этом документе: